Skip to main content

微服务架构 （micro services）

微服务架构和微服务​

  • 微服务架构：

    • 微服务架构 是一种具体的 设计实现 或者 设计方案 ，是将复杂的系统使用 组件化 的方式进行拆分，并使用 轻量级 通讯方式进行整合的一种设计方法。

  • 微服务：

    • 微服务 是 微服务架构 具体的实现方案，是通过 微服务架构 设计方法拆分出来的一个独立的 组件化 的小应用。

微服务架构定义的精髓，可以用一句话来描述，那就是“分而治之，合而用之”。将复杂的系统进行拆分的方法，就是“分而治之”。 分而治之，可以让复杂的事情变的简单，这很符合我们平时处理问题的方法。 使用轻量级通讯等方式进行整合的设计，就是“合而用之”的方法，合而用之可以让微小的力量变动强大。

什么是单体架构​

单体架构 在中小企业内部用的是非常多的，当业务不复杂，团队规模不大的时候，单体架构 比 微服务架构 具有更高的生产率。2017年前的淘宝都是单体架构。

什么是微服务架构​

微服务架构 是将一个单一应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中，服务间通信采用的轻量级通信机制（通常用 HTTP 资源 API ），这些服务围绕业务能力构建并且可通过全自动部 署机制独立部署。这些服务公用一个最小型的集中式的管理，服务可用不同的语言进行开发，使用不同的数据储存技术。

注意

下面示例中的服务器和数据库也可以使用 docker 容器实现

单体架构的程序部署在单台服务器​

这种架构是目前中小企业用的最多的架构。其中 web服务（nginx） 、网站程序 、静态资源（图片） 、数据库(Mysql、Redis) 都在一台服务器上面。如果每天网站的 访问IP 在 5万 以下这种架构完全可以应付（服务器配置也有关系）。

Alternate text

单体架构的程序部署在多台服务器（负载均衡）​

把我们的程序部署到多态服务器上面，然后通过 nginx 配置负载均衡，当客户访问我们的项目的时候随机的分配给不同的服务器处理响应，这样可以防止宕机，提升系统运行稳定性。

Alternate text

单体架构的程序部署在多台服务器（负载均衡+主从数据库）​

这样的架构能轻松的应对每天几百万、上千万的访问量

Alternate text

当每天有上亿访问量，或者更高并发量的时候，上面的方法就有点力不存心了，这个时候我们就可以使用微服务架构。

微服务架构​

  • 微服务架构：
    • 通俗的讲就是把单体架构项目抽离成多个项目（服务），部署到多台服务器。

如果用“茶壶煮饺子”来打比方的话，原来我们是在一个茶壶里煮很多个饺子，现在（微服务化之后）则基本上是在一个茶壶煮一个饺子， 而这些饺子就是服务的功能，茶壶则是将这些服务功能打包交付的服务单元。

Alternate text Alternate text Alternate text

微服务架构和单体式架构区别​

单体式架构服务​

  • 单体架构的优点：

      1. 部署简单：
      • 由于是完整的结构体，可以直接部署在一个服务器上即可；
      1. 技术单一：
      • 项目不需要复杂的技术栈，往往一套熟悉的技术栈就可以完成开发；
      1. 用人成本低：
      • 单个程序员可以完成业务接口到数据库的整个流程；
      1. 项目管理相对较易；
      1. 测试相对简单直观；
      1. 应用开发相对简单；
      1. 横向扩展容易;

  • 单体架构的缺点：

      1. 系统启动慢，一个进程包含了所有的业务逻辑，涉及到的启动模块过多，导致系统的启动，重启周期边长；
      1. 系统错误隔离性差，可用性差，任何一个模块的错误可能导致整个系统的宕机；
      1. 可伸缩性差，系统的扩容只能对整个应用扩容，不能做到对整个功能点进行扩容；
      1. 线上问题修复时间长，任何一个线上问题修复需要对整个应用系统进行全面升级；
      1. 交付周期长(需求->设计->开发->测试->现场实施部署，就传统性质的企业而言)；

微服务​

  • 微服务的优点：

    1. 易于开发和维护：一个服务只关注一个特定的业务功能，所以它业务清晰，代码量少。开发和维护单个微服务相当简单。而整个应用是若干个微服务构建而成的， 所以整个应用在被维持在一个可控的状态；
    2. 单个服务启动快：单个服务代码量少，所以启动快；
    3. 局部修改易部署：单个应用只要有修改，就得重新部署整个应用，微服务解决了这个问题。一般来说，对某个微服务进行修改，只需要重新部署这个服务即可；
    4. 技术栈不受限：在微服务架构中，可以结合业务和团队的特点,合理选用技术栈。例如有些服务可以使用关系型数据库 Mysql， 有的服务可以使用非关系型数据库 redis 。甚至可根据需求，部分服务使用 JAVA 开发，部分微服务使用 Node.js 开发。
    5. 按需收缩：可根据需求，实现细粒度的扩展。例如，系统中的某个微服务遇到了瓶颈，可以结合微服务的特点，增加内存，升级 CPU 或 增加节点 。

  • 微服务的缺点：

      1. 运维成本高
      1. 分部式复杂度高
      1. 接口成本高
      1. 重复性劳动
      1. 业务分离困难

单体架构和微服务架构技术选型​

  • 单体架构已经经历了很多年的考验，2018年前互联网上95%的项目都是单体架构。
      1. 如果您的公司没有运维建议使用单体架构 （小公司）
      1. 如果您的项目并发量不大建议使用单体架构 （一天只有几万的访问量）
      1. 如果您的项目比较简单请建议用单体架构 （小项目）
      1. 如果您的项目并发量非常大建议使用微服务架构或者 serverless 架构（比如：一码通系统、单车系统、物联网平台、物流系统）
      1. 如果您的项目需求经常变化，公司经常要开展线上活动建议使用微服务架构。
      1. 单体架构和微服务架构技术选型需要根据实际情况分析（等学完微服务后您就知道如何选型了）
对比点微服务架构单体架构结论
上手难度API 接口调用数据库共享或本地程序调用单体架构胜
开发效率早期设计和沟通的工作量加大，随着项目规模和时间的推移，效率变化不大早期工作量小，随着项目规模和时间的推移，效率大幅度下降对于简单项目单体架构胜，对于复杂项目微服务架构胜
系统设计（高内聚低耦合）每个业务单独包装成一个微服务，数据和代码都从物理上隔离开来，实现高内聚低耦合相对容易以包的形式对代码进行模块划分，控制得当即可实现高内聚，但最终都是在数据层面将整个系统耦合在一起。微服务架构胜
系统设计（扩展性）独立开发新模块，通过 API与现有模块交互在现有系统上修改，与现存业务逻辑高度耦合。微服务架构胜
需求变更响应速度各个微服务组件独立变更，容易实施敏捷开发方法需要了解整个系统才可以正确修改，容易导致不相关模块的意外失败微服务架构胜
系统升级效率各个微服务组件独立升级，上手和开发效率高，影响面小需要了解整个系统才可以正确修改，容易导致不相关模块的意外失败微服务架构胜
运维效率大系统被拆分为多个小系统，部署和运维难度加大，但可以利用 DevOps 等方式将运维工作自动化简单直接单体架构胜
代码复用性微服务组件可以在新项目中直接复用，包括前端页面一般以共享库的形式复用后台代码微服务架构胜
硬件需求按需为不同业务模块伸缩资源节点，一个系统需部署多个微服务，需要启动多个运行容器整个系统只需要一个运行容器，为整个系统分配资源对于简单项目单体架构胜，对于复杂项目微服务架构胜
项目成本项目早期和后期，成本变化曲线平缓项目早期成本低，后期成本大对于简单系统单体架构胜，对于复杂系统微服务架构胜
非功能需求为单独的微服务按需调优，甚至更换实现方式和程序语言为整个系统调优，牵一发而动全身微服务架构胜
职责、成就感拥有明确的职责划分，主人翁意识和成就感加强，容易形成自组织型团队职责不明确，容易产生扯皮行为微服务架构胜
风险大系统被拆分为小系统，风险可被控制在小系统内，但也引入了各小系统之间的交互风险系统是一个整体，一荣俱荣，一损俱损。微服务架构胜